Add an initial version of a preferences dialog - #2261

Great that you like the UI files 👍

If your solution for translations can be supported by GirCore we can try to upstream it or parts of it. There is already a ticket to improve the UI file translation situation but without any concrete idea yet: gircore/gir.core#1482

One option would be to extend the AssemblyResource loader with an additional step that parses the xml file and replaces any translatable strings (probably fairly similar to what the Parabolic app is doing already). The parsing code could be upstream, and then users would just need a way to provide their translation function (e.g. subclassing the default implementation, or implementing some interface that's provided to the loader, etc)
That's probably the most generic way to handle it, especially for apps like Parabolic which have multiple frontends and might want to use some other library for translations

The other approach I've been looking at is just having Pinta use the native gettext functions for its translations, instead of the managed library we've been using - PR #2263. We used to do this back in the GTK2 days, where gtk-sharp had a wrapper Mono.Unix.Catalog

We already bundle libintl since it's used by GTK, libadwaita, etc, so using this is pretty reasonable and just requires a few bindings for the native functions. The .ui translations then just work without any extra steps since GTK translates them using the native gettext library when loading the files

I think you can already provide custom resource loaders so influencing the xml is already possible. Adding another configuration point inside it feels a little much to me.

It sounds pretty great to use the gettext package. One idea which came to my mind is to just let the user use an attribute on assembly level like SetupGettextAttribute(...) which then generates the code inside GirCore.Integration.Initialize();.

In this way if you call it everything gets setup automatically including language and subclass registration.

Agreed, I think it should be doable as-is to provide a custom resource loader - it's just more work to implement the parsing. But IMO using the native gettext will probably be the easiest avenue for most users.

Initializing gettext can involve some runtime configuration (e.g. to come up with the folder path that gettext should load from, or possibly changing the language-related env vars to override the default language selection), so my initial thinking was to just start with some straightforward bindings that mirror the C api before trying to come up with a higher-level utility?

Yes this would be possible too. I suggested the attribute instead of an API because:

• it's not clear were to put the API, inside a new Nuget?
• it's not a GObject based library

If I use an attribute and generate the code in the user project I don't need a new Nuget and it's more like a configuration. I don't know if there are lots of possibilities to use gettext? I thought it's always the same 3 calls in order and that's it. Do you know otherwise?